Historically, the use of web application code has been split between origin servers and browsers that are connected to one another by a network that transmits data from point to point. Initially, large websites and web applications were first run on large physical mainframe servers that could handle large traffic loads and large data transfers. Over time a switch was made to provide websites and web applications on tens to hundreds of commodity servers that allowed for a reduction in cost, more fault tolerance, and increased performance. This technology is referred to as cloud computing. The technology for providing web applications further evolved to utilize virtual machines where one physical machine could be split into multiple virtual machines that can be independently managed. Virtual machines typically have a high overhead cost in terms of compute resources. For instance, each virtual machine is typically allocated hundreds of megabytes of random-access memory (RAM) and typically takes tens of seconds to boot. Virtual containers can be used to provide isolation between customers of the cloud computing platform and are less resource intensive than virtual machines. However, web application code running in a container typically is run in its own OS-level process, consuming RAM, and inducing context-switching overhead. While native code can load quickly in a container, many server-oriented language execution environments are not optimized for startup time.
Some cloud computing platforms instantiate a containerized process for customer code and auto-scale the process which creates cold-starts. A cold-start occurs when a new copy of the code starts on a physical machine. When a new containerized process is instantiated it can take between hundreds of milliseconds to multiple seconds (e.g., between 500 ms to 10 seconds) to complete. This means that any request to be serviced by the code to be executed in a container may be waiting for as much time as it takes to start execution of the new containerized process (e.g., for as much as ten seconds). Also, this containerized process can only process a single request at a time and a new containerized process must be cold-started each time an additional concurrent request is received. This means that each such request to be serviced by a new container can experience significant lag that does not improve over time. If the containerized process does not receive a request to be processed within a certain amount of time, it will automatically terminate and a new containerized process will need to be cold-started again once a request is received. When new customer code is deployed, this entire process proceeds again as each containerized process needs to be instantiated anew.
In these complex cloud computing platforms, security can be difficult to maintain. Hackers can attack websites in many different manners. In some cases, hackers seek to find a mechanism to get an origin server to execute injected scripts. One mechanism to prevent such attacks is the use of a nonce value in legitimate scripts in the content items provided by an origin server. The injected scripts do not contain a nonce value that matches a nonce value provided by an origin server and can then be identified and blocked from execution. Since nonce values are generated by an origin server, content items that contain nonce values cannot be cached in other locations to reduce latency, because the nonce value and content item are generated by the origin server and cached copies would not have proper nonce values that can protect the content item.